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TUNABLE INFORMATION PRESENTATION APPLIANCE USING AN 
EXTENSIBLE MARKUP LANGUAGE 

TECHNICAL FIELD 

The invention relates generally to providing a mechanism to allow a user to tune an 
information presentation appliance and, more particularly, relates to extending a profile of a 
self-configuring information presentation appliance through the use of an extensible markup 
language. 

BACKGROUND OF THE INVENTION 

An increasing number of common household items are evolving into computing 
machines capable of network communication. The goal of such an evolution is to allow 
appliances throughout a home to communicate with one another so that the user can simplify 
his or her lifestyle. For example, many common household items, including ovens, 
microwaves, video devices, radios and alarm clocks each contain a time display. However, 
because such appliances cannot currently communicate with one another, the user is forced to 
set the correct time on each appliance. Inter-appliance communication would allow a single 
appliance to share the correct time with all of the other appliances, minimizing the effort on 
the part of the user. Such efficiencies, however, require creating and managing a 
communications network connected to many different appliances. 

To ease the burden of setting up a communication-capable appliance and integrating it 
into such a network, a number of technologies and protocols have been developed which 
allow appliances to configure themselves. One such technology is known as Universal Plug 
and Play (UPnP) and defines a mechanism by which an appliance can automatically learn of 



other appliances and integrate itself into the network. The UPnP architecture defines two 
categories for appliances: a "device" category, containing those appliances which can receive 
instructions and perform functions, and a "control point" category for those appliances which 
can send instructions and thereby control devices. A UPnP device can advertise the "services" 
it is capable of performing by broadcasting a message throughout the communication network 
to which it is attached. The message containing the services can be detected by a UPnP 
control point and, if the control point is interested in the services exposed by the device, it can 
query the device for further information regarding those services and learn how to control 
those services. 

From the perspective of the user, UPnP devices and control points are setup-free: the 
user merely plugs them into the communication network, and the appliances configure 
themselves. Thus, a user having a UPnP compliant oven, microwave, video device, radio and 
alarm clock need not spend the time and effort to determine the correct time and set the time 
on each appliance. Instead the user can simply attach a control point, such as a personal 
computer, and the control point will learn of each device connected to the communication 
network. A single instruction from the user to a control point can be used to set the correct 
time on each device, saving the user from the burden of setting each separately. 

However, the current UPnP implementation does not provide any mechanism by 
which a device or control point can automatically tune or filter the information it displays to 
the user. For example, a device is limited by its functionality to displaying whatever 
information it is provided by a control point. Thus, an LCD picture frame, for example, will 
display all of the pictures sent to it by a control point, and a speaker, such as a radio or stereo 
system, will play whatever audio data it receives from a control point. A control point will 
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allow user control over the pictures sent to the picture frame or the audio sent to the speaker, 
for example, but it requires the user to perform the filtering. Thus, a user seeking to send one 
set of pictures to an electronic picture frame in a home office, and another set to an electronic 
picture frame in a family room must explicitly define each set at the control point and direct 
5 each set to a particular picture frame. If the user subsequently moves the picture frame from 
the home office into the bedroom, the user is forced to explicitly define a new picture set for 
the bedroom at the control point, and direct it to the picture frame now located there. 
Similarly, if the user has a personal computer set up as a control point, with a broadband 
u connection to a network such as the Internet, through which the user receives digital radio 
p 10 stations, the user will be forced to select the radio stations played by the speaker at the control 
%J point instead of at the speaker. Ultimately, the user is continually forced to perform any 

4= tuning of the content presented on their own and only at the control point. 

Ill 

q SUMM ARY O F THE INVENTION 

□ 15 The present invention, therefore, is directed to a method, system, and apparatus which 

allow a user to tune the content presented on an intelligent information presentation appliance. 

The present invention is also directed to a method, system, and apparatus which allow 
appliances that traditionally acted as devices to act as control points within the UPnP network 
structure. 

20 The present invention is additionally directed to a method, system, and apparatus 

which allow the definition of a device or a control point within the UPnP network structure to 
be extended via an extensible markup language such as XML. 



The present invention provides a tuning capability for information presentation 
appliances by extending the definition of the appliance, whether it is a UPnP device or control 
point. The appliance can contain a user interface, in either hardware or software, for tuning 
the information presented by the appliance. An extension to a standardized XML schema is 
5 contemplated, wherein the additional elements represent categories of information from which 
the user can select. In such a manner, the user's tuning can be transmitted through XML 
pages which remain backwards compatible. If the appliance is a control point, the user's 
tuning can be detected and represented in an extended XML schema so that the control point 
A can instruct information sources, such as compatible Internet radio station servers or image 
3 10 servers, to send only specific categories of information reflecting the user's tuning. If the 
: i appliance is a device, it can advertise its methods, through an extended XML schema, as being 
f_ capable of presenting only those categories of information reflecting the user's tuning. To 
A devices and control points which do not contain the functionality of the present invention, the 

2 extensions to the XML schemas contemplated by the present invention are ignored, thereby 

3 1 5 ensuring backwards compatibility with older devices. 

351 

Additional features and advantages of the invention will be made apparent from the 
following detailed description of illustrative embodiments which proceeds with reference to 
the accompanying figures. 
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BRTEF DESCRIPTION OF THE DRAWINGS 

While the appended claims set forth the features of the present invention with 
particularity, the invention, together with its objects and advantages, may be best understood 
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from the following detailed description taken in conjunction with the accompanying drawings 
of which: 

Figure 1 is a block diagram generally illustrating an exemplary display apparatus for 
use with the present invention; 
5 Figure 2 is a block diagram generally illustrating an exemplary computing device for 

use with the present invention; 

Figure 3 is a cross-sectional diagram generally illustrating a home in which the present 
invention can be used; 

^ Figure 4 is a block diagram generally illustrating a series of communications common 

p 10 in an architecture with which the present invention can be used; 

jJ Figure 5 is a block diagram generally illustrating a series of communications 

J! contemplated by the present invention; 

J\ Figure 6 is a block diagram generally illustrating a series of alternate communications 

q contemplated by the present invention; and 

.-.SK. 

CI 15 Figure 7 is a user interface diagram generally illustrating an exemplary user interface 

contemplated by the present invention. 



DETAILED DESCRIPTION OF THE INVENTION 

The present invention is directed to a method, system, and apparatus for providing 
20 tuning ability to appliances which present content to a user. A audio and/or video presentation 
appliance, such as an electronic picture frame (EPF), television, decoder device, set-top box, 
stereo system, radio, and the like, can be directly tuned by a user through the selection of 
categories of information presented through a user interface. Following a standard Universal 
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Plug and Play (UPnP) architecture, the present invention contemplates extensions to the 
extensible Markup Language (XML) schemas used to define a device and the services 
exposed by that device. A control point can use these extensions to determine the categories 
of information which can be presented to the user through the device. The user can then select 
5 from amongst these categories, thereby tuning the information presentation appliance. 

Alternatively, the user can select from a predefined set of categories and the device can create 
a device description that advertises the device as capable of presenting the selected categories. 
The device will, thereby, receive only those categories of information from an information 
, 2 store at a control point, or through a control point. In either case, the user is not required to 
p 10 pre-define the information that can be delivered to an information presentation appliance from 
: >J an information store, but can tune the appliance as desired. 

jF Turning to the drawings, wherein like reference numerals refer to like. elements, the 

jps 2 

: . invention is illustrated as being implemented in a suitable computing environment. Although 
~* not required, the invention will be described in the general context of computer-executable 
o 15 instructions, such as program modules, being executed by a computing device. Generally, 
program modules include routines, programs, objects, components, data structures, etc. that 
perform particular tasks or implement particular abstract data types. Moreover, those skilled 
in the art will appreciate that the invention may be practiced with many different computer 
system configurations, including hand-held devices, multi-processor systems, microprocessor 
20 based or programmable consumer electronics, network PCs, minicomputers, mainframe 
computers, intelligent appliances, and the like. The invention may also be practiced in 
distributed computing environments where tasks are performed by remote processing devices 
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that are linked through a communications network. In a distributed computing environment, 
program modules may be located in both local and remote memory storage devices. 

Figure 1 illustrates an example of an intelligent appliance for use with the present 
invention. An information presentation appliance 1 can either present information to a user 
5 through a video device 2 or a sound device 3. The video device can be a television, an LCD 
panel, an EPF, a projection screen, or the like. Similarly, the sound device 3 can be a speaker, 
a stereo system, a radio, or other sound transducer. While it is possible that a single 
information presentation appliance 1 can have both audio and video output, such as a 
television set, it is also contemplated that the information presentation appliance can have 
Jf 10 only one, such as a simple, low-cost, EPF. Furthermore, it is not intended that the present 

TOST 

Tj invention be limited to information presentation appliances which can only deliver 

information through sound or audio. For example, an information presentation appliance 1 

s can be a decoder device or set-top box. As is know by one of skill in the art, such devices do 

not provide direct audio or video output to a user, but instead decode one signal and present it 

S; 15 in another format to another information presentation appliance. The present invention 

contemplates information presentation appliances, such as decoder devices, or set-top boxes, 
which can receive information over a network, as will be described in detail below, and 
present it in a common format, such as an interlaced video stream, or an pre-amplified audio 
stream to a less sophisticated information presentation appliance, such as a common TV or 
20 stereo system. 

The information presentation appliance 1 can be connected to a UPnP network 4, 
which will be described in further detail below, through a network interface 5. A processing 
unit 6 can perform the steps required by the present invention and, in the process, can use the 
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system memory 7, which can be volatile and/or nonvolatile memory such as read only 
memory (ROM) 8 and random access memory (RAM) 9. A basic input/output system (BIOS) 
10, can contain the basic routines that help to transfer information between elements within 
the information presentation appliance 1, such as when the appliance is turned on or plugged 
into an electrical outlet. Such BIOS 10 is typically stored in ROM 8, together with a minimal 
operating system 1 1 which can contain the necessary interfaces to enable the operation of 
higher level programs or instructions. RAM 9 typically contains data and/or program modules 
that are immediately accessible to and/or presently being operated on by processing unit 6. 
The program modules 12 and program data 13 can contain the necessary information to 
operate the appliance 1, and enable the appliance to communicate over the network 4. 

As the invention is directed to the ability of a user to tune the content which is 
displayed by an appliance, such as information presentation appliance 1, the information 
presentation appliance can contain an input interface 16 for accepting user input. A variety of 
user input devices can be used, such as a mouse 17, a keyboard 18, or built-in devices, such as 
a touch-screen or a jog-dial, not shown. Generally, the type of input device will be 
determined by the intended use of the information presentation appliance 1, and its target cost. 
The input interface 16 can communicate with the other elements of the information 
presentation appliance 1 though a system bus 19. The system bus 19 can be any type of bus 
structure including a memory bus or memory controller, a peripheral bus, and a local bus 
using any of a variety of bus architectures, including wire-based and wireless architectures. 

Figure 2 illustrates an example of a suitable computing device 20 with which the 
invention may be implemented. The computing device 20 is only one example of a suitable 
computing environment and is not intended to suggest any limitation as to the scope of use or 
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functionality of the invention. Neither should the computing device 20 be interpreted as 
having any dependency or requirement relating to any one or combination of components 
illustrated in the exemplary computing device 20. Components of the computing device 20 
may include, but are not limited to, a processing unit 21, a system memory 22, and a system 
5 bus 23 that couples various system components including the system memory to the 

processing unit 21. The system bus 23 may be any of several types of bus structures including 
a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of 
bus architectures including wire-based and wireless architectures. By way of example, and 
not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro 

IL~£. 

y 10 Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards 

u 

rj Associate (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as 
£ Mezzanine bus. 

is Computing device 20 typically includes a variety of computer readable media. 

^ Computer readable media can be any available media that can be accessed by computing 
15 device 20 and includes both volatile and nonvolatile media, removable and non-removable 
media. By way of example, and not limitation, computer readable media may comprise 
computer storage media and communication media. Computer storage media includes both 
volatile and nonvolatile, removable and non-removable media implemented in any method or 
technology for storage of information such as computer readable instructions, data structures, 
20 program modules or other data. Computer storage media includes, but is not limited to, 
RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital 
versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, 
magnetic disk storage or other magnetic storage devices, or any other medium which can be 
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used to store the desired information and which can be accessed by computing device 20. 
Communication media typically embodies computer readable instructions, data structures, 
program modules or other data in a modulated data signal such as a carrier wave or other 
transport mechanism and includes any information delivery media. The term "modulated data 
5 signal" means a signal that has one or more of its characteristics set or changed in such a 
manner as to encode information in the signal By way of example, and not limitation, 
communication media includes wired media such as a wired network or direct- wired 
connection, and wireless media such as acoustic, RF, infrared and other wireless media. 
Combinations of the any of the above should also be included within the scope of computer 
S 1 0 readable media. 

%j The system memory 22 includes computer storage media in the form of volatile and/or 

Hp nonvolatile memory such as ROM 24 and RAM 25. A BIOS 26, containing the basic routines 

iy 

that help to transfer information between elements within computing device 20, such as 
J- during start-up, is typically stored in ROM 24. RAM 25 typically contains data and/or 
g 1 5 program modules that are immediately accessible to and/or presently being operated on by 
processing unit 21 . By way of example, and not limitation, Figure 2 illustrates operating 
system 35, application programs 36, other program modules 37, and information storage 38, 
which can include such items as a collection of images 43 or a collection of audio files 44. 
The computing device 20 may also include other removable/non-removable, 
20 volatile/nonvolatile computer storage media. By way of example only, Figure 2 illustrates a 
hard disk drive 27 that reads from or writes to non-removable, nonvolatile magnetic media 
such as hard disk 60, a magnetic disk drive 28 that reads from or writes to a removable, 
nonvolatile magnetic disk 29, and an optical disk drive 30 that reads from or writes to a 



11 

removable, nonvolatile optical disk 3 1 such as a CD ROM or other optical media. Other 
removable/non-removable, volatile/nonvolatile computer storage media that can be used in the 
exemplary operating environment include, but are not limited to, magnetic tape cassettes, 
flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state 
5 ROM, and the like. The hard disk drive 27 is typically connected to the system bus 23 

through a non-removable memory interface such as interface 32, and magnetic disk drive 28 
and optical disk drive 30 are typically connected to the system bus 23 by a removable memory 
interface, such as magnetic disk drive interface 33 and optical disk drive interface 34. 
L . The drives and their associated computer storage media discussed above and 

O 10 illustrated in Figure 2, provide storage of computer readable instructions, data structures, 
SI program modules and other data for the computing device 20. In Figure 2, for example, hard 
J~ disk 60 is illustrated as storing operating system 35, application programs 36, other program 
modules 37, and information store 38. A user may enter commands and information into the 
q computing device 20 through input devices such as a keyboard 40 and pointing device 42, 
O 1 5 commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) 
may include a button, microphone, joystick, game pad, satellite dish, scanner, or the like. 
These and other input devices are often connected to the processing unit 21 through a user 
input interface 46 that is coupled to the system bus, but may be connected by other interface 
and bus structures, such as a parallel port, game port or a universal serial bus (USB). A 
20 monitor 47 or other type of video presentation appliance can also connected to the system bus 
23 via an interface, such as a video interface 48, and a computer speaker 56 or other type of 
audio presentation appliance can be connected to the system bus 23 via an interface, such as 
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an audio interface 55. In addition to the monitor and speaker, computing devices may also 
include other peripheral output devices, such as printers, which are not shown. 

The computing device 20 may operate in a networked environment using logical 
connections to one or more remote computers. The logical connections depicted in Figure 2 
5 include a local area network (LAN) 5 1 and a wide area network (WAN) in the form of 
Internet 50, but may also include other networks, such as intranets, and are not meant to be 
limited to networks using TCP/IP communication. When used in a LAN networking 
environment, the computing device 20 is connected to the LAN 51 through a network 
H interface or adapter 53. The computing device 20 shown in Figure 2 is networked, via LAN 
J=3 1 0 5 1 , to a broadband modem 49, such as a cable modem, a Digital Subscriber Line (DSL) 
si modem, satellite modem, or the like. A broadband modem 49 connected to the LAN 51 
rij allows multiple computing devices to share the same broadband connection, allowing more 
H users faster access to WANs such as Internet 50. Alternatively, the computing device 20 can 
U include a modem 54 or other means for establishing communications over the WAN, such as 
'yj 15 the Internet 50. The modem 54, which may be internal or external, may be connected to the 
system bus 23 via the serial port interface 46. In a networked environment, program modules 
depicted relative to the computing device 20, or portions thereof, may be stored in the remote 
memory storage device. It will be appreciated that the network connections shown are 
exemplary and other means of establishing a communications link between the computers 
20 may be used. 

In the description that follows, the invention will be described with reference to acts 
and symbolic representations of operations that are performed by one or more computer, 
unless indicated otherwise. As such, it will be understood that such acts and operations, 
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which are at times referred to as being computer-executed, include the manipulation by the 
processing unit of the computer of electrical signals representing data in a structured form. 
This manipulation transforms the data or maintains it at locations in the memory system of the 
computer, which reconfigures or otherwise alters the operation of the computer in a manner 
well understood by those skilled in the art. The data structures where data is maintained are 
physical locations of the memory that have particular properties defined by the format of the 
data. However, while the invention is being described in the foregoing context, it is not meant 
to be limiting as those of skill in the art will appreciate that various of the acts and operation 
described hereinafter may also be implemented in hardware. 

Turning to Figure 3, the operation of a Universal Plug and Play (UPnP) network 4 can 
be illustrated in the context of an average home 100, having a master bedroom 102, a kitchen 
104, a living room 106, an office 108, and a kids bedroom 110. The UPnP network 4 can be 
connected to appliances through various different ports. For example, computing device 20 
can be connected to the UPnP network 4 through the network interface 53 or the serial port 
interface 46. One preferred embodiment uses network interface 53 to connect the computing 
device 20 to the UPnP network 4 because the network interface 53 provides efficient 
throughput of data using the standard networking protocols relied on by the UPnP 
architecture, as explained below. Alternatively, the UPnP network 4 can also be connected to 
computing device 20 through the video interface 48 or the audio interface 55, for networking 
presentation appliances which can present video or audio data, respectively. The computing 
device 20 can maintain a connection to the Internet 50, through a broadband connection 1 12, 
and can share the connection 112 through the UPnP network 4. The broadband connection 
1 12 can use a broadband modem 49, or other broadband connection hardware. Additional 



14 

devices or control points can be attached to the network 4, and can share the resources of the 
other devices or control points. 

As will be known by those of skill in the art, the UPnP Architecture, as expressed in 
The Universal Plug and Play Device Architecture Version 1 .0, incorporated herein by 
reference in its entirety, defines UPnP compliant appliances as either "devices" or "control 
points." A UPnP device advertises its abilities and is controlled by a control point, while a 
control point listens or searches for devices it is capable of controlling. The office 108 
contains the computing device 20, which often acts as a control point. The computing device 
20 searches for, and listens to, devices on the UPnP network 4. An exemplary UPnP device 
can be a printer 1 16 attached to the network 4. When the printer 1 16 is initially connected, it 
advertises its services, such as printing, form feeding, envelope feeding, and the like. The 
control point, in the form of computing device 20, listens for such advertisements, and when 
they are received, responds with a request for further information if the control point is 
interested in the service advertised by the device. 

The UPnP architecture relies on well known networking protocols, such as the 
Transfer Control Protocol (TCP), the Internet Protocol (IP) and the HyperText Transfer 
Protocol (HTTP). Thus, when the printer 116 advertises its services, it sends a file through 
HTTP using a markup language. The extensible Markup Language (XML) can be used by the 
UPnP architecture to transmit information between devices and control points. The file sent 
by the printer 1 16 to advertise its services can be a page written in XML, specifying 
information about the printer, the services it provides, and the address of additional pages of 
information regarding each of the services advertised. In such a manner, the control point 
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need only issue the well known HTTP "get" request on one of the pages specified by the 
printer 1 16 to obtain further information and learn how to control the printer. 

Table 1 below illustrates a sample XML page that could be sent by printer 1 16 to 
advertise its services. As will be known by those skilled in the art, XML classifies data 
contained within the document by using tags, which are identified by brackets. For example, 
a <device> tag indicates the beginning of a set of data about a device, and a </device> tag 
indicates the end of the set of data about the device. Because XML is extensible, new tags can 
be defined through an XML schema, as will be described further below. An XML document, 
such as that shown in Table 1, can reference an appropriate schema in order to provide a 
context and meaning for the tags used in the document. The first two lines of Table 1, for 
example, identify the version of XML used, and the schema document that provides the 
definitions of the tags used. 

The "device" element in Table 1, identified and bounded by the <device> and 
</device> tags, contains the description of the printer 116 and can contain a number of sub- 
elements which provide the structure through which the printer can advertise itself and its 
services. For example, the "manufacturer" sub-element can provide the name of the 
manufacturer of the printer, the "modelName" sub-element can provide a model name the 
printer was assigned by its manufacturer, and the "modelNumber" sub-element can provide a 
model number which was assigned to the printer. The "device" element also contains the 
"serviceList" sub-element, which can list services offered by printer 116 through further sub- 
element "service". Table 1 illustrates one "service" element used to provide information on 
the printing service. The "service" element, in turn, has sub-elements which can define a 
service identifier (the "serviceld" sub-element), a Uniform Resource Locator (URL) of a page 
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with more information about the sendee (the "SCPDURL" sub-element), and a URL of a page 
which can be used to control the service (the "controlURL" sub-element). Additional services 
can be listed under the "serviceList" element through the use of more "service" sub-elements 
as shown in Table 1 below. 

<?xml version= n LO"?> : ' : : - ; " ' • \ : l!; I !; ] : ./,; T : ~~ T ~7~7~~ 
<root xmlns= M um:schemas-upnp-ofg:device-l -0 M >t \ _ - : I : - A 

llftf ,<speeVersiom> t ; y " '" { ,l ,l * :> * : ' ' r ' : ' \ «„, < n 8 , / <. - u * : r ; :\. . - - 

<mai or> 1 </m^^H( ; - 1 » jj : f < <> .< , • 

<minpr>0</minor> ^ , > ; r , 

</specVersiori> 

<device> . _ , : ; : \ - : > — - » - ■ - • * ( _ ; < 

<deviceType>^ 

< <fnenc^ ' ; ; , • : v : : < / * , > - ' . ' •;>'<;<; 

<manufacturer>PrinterC^ ; ,* \ • . . ,w ; 

> <manufacturerU3^ 
<modelDescriptidn>Ink Jet Printer</modelDescription> 
<modelName>JetPrint</modelName> 
; u - . <modelNumber>10G</modelNiimber> 
; <modelUM>htt^://w^^ 

: <serialNumber>123r45:678#<^e^ . 
III - <UDN>1234:567</U-DN>' 
<UPC>JPlpO-1234</UPC> 
<serviceList> \.//}' V - ^ 
<service> ' ! 

<servicettl3fe>urn:schemas-upnp-org;service:print: l</serviceType> 
<sefviceId>irai:upnp-org:serviceId:pr 
<SCPpURL^print.xml</SCPDURl> ; ' ; 1 , ,, 
<contrblURlL>printcontrol.xml</contrp^ ; , . 

</service> . • > ' - < < < 

<service> ^ _ , , 1 , - .f 

, -- a second service jcan^be described here — , . 

</service> / " :\ , - „ i r _ ' ' r < 

lllll ' , </serviceList> - ; ' 

. % , </device> . . - , - • ; : ; - 

</root> ^ : ; " < • 

TABLE 1 

Returning to Figure 3, if the control point, as implemented by computing device 20, 
needed further information regarding one of the services advertised by the printer 1 16, it can 
issue the HTTP "get" command on the file specified by the "SCPDURL" sub-element within 
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the "service" element. Thus, per the example in Table 1, the control point can issue a "get" 
command on the file "print.xml" to obtain further information regarding the print service, 
including information on arguments to be passed, variable to be used, and the data type, range, 
and event characteristics of each. Armed with this information, the control point can 
5 formulate an appropriate command, such as a request to print a specified page on a specified 
paper type, using a specified quality of printing, and can send the request to the page specified 
in the <controlURL> tag. 

Figure 4 illustrates an exemplary set of communications between a control point 150, 
in the form of computing device 20, and a device 152, in the form of printer 116. Initially, as 
5J 10 described above, the device 152 advertises its standard services in step 156 by sending an 

K g jj 

7j XML file such as the one shown in Table 1 . If the control point 1 50 is interested in the 
jr services advertised, it can request a service information page at step 1 57, such as page 

a "print.xml" identified in the device description page of Table 1 . At step 158, the device 1 52 

can respond by sending the requested page, which can contain further information regarding 
2} 15 the service 154, as described above. The control point 150 can then request an action in step 
1 59 by sending an HTTP "post" message to the page for the service 1 54, such as the page 
"printcontrol.xml" specified in Table 1, using the arguments and variables specified by the 
service information page returned at step 158. The device 152 will perform the action 
requested at step 159 and can change certain state variables as a result of the performance of 
20 the action. These state variables can then be communicated to the control point 1 50 in a 

response message 160, as indicators that the action was performed. Should the control point 
150 require further information, it can query specific variables at step 161 in the same manner 
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as requesting an action to be performed (e.g. with an HTTP "post" message), and the values of 
the requested variable can be returned by the service 154 at step 162. 

As can be seen, the UPnP architecture allows devices and control points to establish 
communication with one another and allows control points to learn the functions offered by 
5 devices with no interaction on the part of the user. Returning to Figure 3, the printer 1 16 need 
only have been plugged into the UPnP network 4 and the control point 150, implemented in 
computing device 20, would have been able to locate the printer 116 and use it. 

In a similar manner, many types of devices can be connected to a UPnP network, such 
as network 4. For example, television sets, such as televisions 120, 128, and 134 can act as 
O 10 UPnP devices in a manner similar to printer 1 16. Similarly, electronic picture frames (EPFs) 

if"! 

J*? 124, 126, and 132, as well as stereos, such as stereo 122 or 130, can all act as UPnP devices. 

fli 

j= In a manner similar to printer 116, each of these devices will advertise their services by 
9 broadcasting an XML file, such as that shown in Table 1 . Of course, the XML file of Table 1 

M 5 references an XML schema for printers: "um:schemas-upnp-org:device:printer: 1 " A different 
•C 1 5 schema can be used for each of the other types of devices on network 4, shown in Figure 3. 
For example, televisions 120, 128, and 134 can be described by an XML file referencing a 
television schema, such as "urn:schemas-upnp-org:device:television:r ? . Similarly, schemas 
"urn:schemas-upnp-org:device:epf:l" and "urn:schemas-upnp-org:device:stereo:l" can exist 
for creating XML files describing EPFs 124, 126, and 132 and stereos 122 and 130, 
20 respectively. 

As is known by those of skill in the art, a schema defines a class of XML documents. 
Each of the tags, or elements, in an XML document can be defined in the schema the XML 
document has referenced. Elements can be simple, in that they contain merely numbers or 
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characters, or they can be complex and contain sub-elements, some of which may have further 
sub-elements still. Table 2 below contains an exemplary XML schema defining a class of 
XML documents to which the exemplary device description document in Table 1 belongs. As 
can be seen from Table 2, elements are defined in terms of sub-elements, or of simple data 
types. Thus, the element "roof (identified by the <root> tag in Table 1 above) contains an 
element named "specVersion" and an element named "device." Referring back to Table 1, it 
can be seen that the root element contains only the two sub elements enumerated in the 
schema in Table 2: the "specVersion" element and the "device" element. Each of the 
elements "specVersion" and "device" is also defined in the schema. The element 
"specVersion" contains two sub-elements: "major" and "minor", each of which are further 
defined as being of type "int" or integers. Because the sub-elements "major" and "minor" are 
simple types, no further levels of definition are necessary, and the element "specVersion" is 
fully defined. The "device" element is similarly defined, having sub-elements, some of 
which, like "deviceType" and "manufacturer" are simple elements, and others, like "service" 
are complex and defined by still further sub-elements that are simple. 



<?xml version-" 1. 0"?> / : - — ; 

<Schema name="device-l r O" i; , ; , - > 

xmlns="um:schemas-microsQ^ * 4 ; 

xmfe ! > 

<ElementTvpe name^'root 1 ' content^" eltOnlY"> ' 

<element typ'e=" specVersion" /> < - , _ 

<element type=" device" /> 
</ElementType> : > - - 

<ElementType naxne="specVersion" content="eltpnlY n> 

<elementtype- 'major" /> 

<element type="rninpr " /> 
</ElementType> » r 

<ElementType name- 'maior" dt:type-"inf" cprrtent- 'textOnly" /> 
<EIementType name- 'minor" dt:type="int" content="textOrily" /> 
<ElementType name- 'device" content="eitOnly"> : , 

<elemerit type~'deviceType"7> , . 

<element type^"fxien:dlyName" /> 

<element type="manufacturer" /> 

<element type="manufacturerURL" mmOccurs- '0" maxOccurs- '1 " /> 
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<elerrient type="iribd6lDescriptibh M minOccurs= T, 0" maxOccurs- 1 F7> 

<element type= M ino'delName" p : > t n \] r . , „ . 

f element tvpe^ ^ m(^delKumbe^ , -mmOccurs- '0 M maxOccurs- ' 1 w /> 

<element ti^e^^modelURL ,f mipQccitfk= i? 0 M maxOcctirs==='T f /> 

<elerrient type="serialNumber M miiiOcqurs^ M G" maxOccurs= r ' l v :/> - < >><,■' ' 
<eleraent tVpe-^UDN" />; o , s H ;j ; ; _ , < ! ^ -N ;> < > ^ ' J : - 

<element type-'URC^mihOecurs- *G"MMM;urs- '1" /> 1 ; i ; <^ ' > „ _ = - 
<element type="serviceList";/> ^ * I: I ' ' - ( ># , J ' ' 4 ' < _ ,< ' r - ' • 

</ElpBientTyp'e> ^ * * '* » ?, < r , , ' " : - ^ " ; < } <„ . 

<ElementTVpe name="deyiceType" dtt^e^Vi" content="tfeit0nly"7> _ I -> < :; 

<EleraentTvpe na^ c0jntent="textQnly n l> * ! j: J 

<ElementType name="niaiiiifacturer" dftf^e^ ,r string rt C0IltentT ,^ MtC)iily , /> - 1 r ' ; 
,<BlementType name="m^iifacturer^^ /> ! 1 '< , : " " « < 

<ElementXw <- < ' ; ; 

<ElementTYpe name= ,r mod&IName w dt:tyjpe= M ^t|mg ,? : content- 'textOiily"}^ 

<ElementType name= M raodeiNumber" dt:type- 'string" content^'textOnly" /> ir i- 

<EiementType name="mbdelU^ n dt:ty^e- M uri n conteii^ ,, teMxilY^/> ( ; \ , , 

<ElementType name="^erialNumb6r" 4fctype=" string" content- 'textOnly" l> 

<ElementType name= M bDN n dt:type-"uri n content= M textOnly TI /> <; ' , 

<EIementType name-"UPC" dt:type="string M content^textOnly" /> . _ * 

<ElementT^ = « . 

<elemerit type- 'service" minOccurs— ^f^maxOccurs^"*'^ ■ :, - . " ; , 

</EIementType> - ] t . t 1 ; ^ - / — 

<ElementType name- 'service!' content- 'eltOnly'^ • \ 
<element type- 'serviceType" /> ' J ' ; 

^element type^'serviceld" /> 4 ! ' - 

<element type="SCPDURL'' />; :| - \\_ • ^ * ' 8 ' . ' . " , 

<element type- 'contrdlURL" /> / '<>«>« ^ t 

<element type- H eventSubURL" />: V : . ( * / ]\ . - > / < - 

</ElementType> ^ ' 4 , > , \ * , > 

<ElementType nairie^'^erviceType" dt:type^ n uri" cojtitent= n textdnly" /> 

<ElementType name==: ,r servicerd" dtitype^^uri" content- 'textOnly ,f /> , . 
<ElementType name="SCPDURL l, dt:tYpe="^lri ,, cdritent= ff textOnly" 'M 1 ' : 
<ElementType name= n contrbl0RL ,r dttype- 'uri" content= , 'tex^(])nly ,, l> ~ <- ' ' 
<ElementType name^'eventSubURL"' d|t|type= H uri M conteiit- ,, textOnly M /> > ; 
</Schema> • ''<''<<><> " ; ( „ , - ~ ; : : 

TABLE 2 

Because a schema defines a class of documents, it is not required that every document 
within that class contain all of the elements defined in the schema. However, a document of 
the class defined by a schema may not contain elements that are not defined within the 
schema. Furthermore, the UPnP architecture implements the Flexible XML Processing 
Profile (FXPP), which specifies that devices and control points can ignore elements, and all 
sub-elements, which are not understood by the device. Thus, a more complex schema can be 
defined, allowing those devices and control points having appropriate capability access to 
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additional features, while maintaining compatibility with older or less advanced devices and 
control points. The older or less advanced devices would simply advertise with an XML page 
that did not use all of the elements contained within the schema defined for that class. 
Similarly, older or less advanced control points would simply ignore those XML elements that 
they did not understand. 

In accordance with one important aspect of the invention, an extended XML schema is 
provided for enabling devices and control points to allow a user of a device access to multiple 
categories of information, allowing the user to tune the information presented through the 
device. The XML schema for UPnP devices can define additional elements, as will be 
explained in more detail below, that can be used by devices and control points to define and 
present categories of information to a user. The additional elements, however, will not 
interfere with the normal operation of a UPnP network, as the additional elements within the 
device description document will be ignored by control points that do not contain the 
capabilities of the present invention. Because the information capable of being presented can 
come in various forms and formats, additional XML schemas are contemplated for various 
types of information presentation appliances. 

In accordance with another important aspect of the invention, information presentation 
appliances which traditionally behaved as devices within the UPnP architecture can act as 
control points, allowing the information presentation appliance greater flexibility in presenting 
categories of information to a user and allowing the user to tune the information presented 
through the appliance acting as a control point. An information presentation appliance, such 
as an EPF, a stereo, or a printer, is generally a device under the UPnP architecture because it is 
controlled by a control point that feeds, or pushes, to the information presentation appliance, 
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the information that the appliance is to present, including images, sound, or hard copy output. 
The present invention contemplates the information presentation appliance as a control point 
within the UPnP architecture, enabling it to request information from information storage 
appliances and servers, which, in turn, would be devices within the UPnP architecture. In this 
manner the information is pulled, or fetched, by the information presentation appliance, rather 
than being pushed to it. 

In accordance with a further important aspect of the invention, an information 
presentation appliance within a UPnP network contains hardware and software for presenting 
categories of information to a user to allow the user to tune the appliance. A user interface is 
contemplated, implemented through various user input devices, which can enable a user to 
select among available categories of information to be presented to the user by each 
information presentation appliance. 

In keeping with the invention, Table 3 illustrates an exemplary extended XML schema 
contemplated by the present invention. For clarity, the additional elements in Table 3, not 
found in Table 2, are shown in bold type. For example, the present invention contemplates an 
additional element, such as that named "informationCategoryList" in Table 3, which allows 
compliant devices to describe the types of information content they can present. As will be 
described further below, the user can be presented with a general listing of categories of 
information, such as styles of music, or genres of images, or categories of video clips, which 
the user can choose to be presented by the particular device. The user's selection can then be 
stored in the device and presented as part of the device information page using the schema of 
Table 3. The "informationCategoryList" element can contain sub-elements to further specify 
the user's selections. In such a manner, the exact title of the category of information selected 
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by the user does not need to be matched, since additional information, such as keywords, can 
be used to more accurately present the user's selections. 



<?xmi versiori4"L0 ?, ?> • s \ , " ' > i : % l ' 

<Schema name- f device- 1-0" ; i 

xmms:dt— 'um:sch^^ ; r , 

<ETementType name= ,? root" cbhtent="eltOnly"> 

<element typ6= ,t specVersion n f> ' ' : . ; / [ \ '* : ; 

<element type~'device" /> ; - ; , : , , * 

</ElementType> f > t i ' ^ . >> : Y i - «? ; . - - 

<Elem content^"eltQnly"> 

<element type="major" /> > - ' r _ 

<element type= n minor" /> ' " 

</ElementType> „ , , : - 

<ElementType name^" major" dtitype^Hnt" eontent="textOnly" /> 
<ElementType name^'miripr" dt:type="int M content="textOnly" f> 
<ElementType name="device (f 'bonter4^"eltOrjily"> 
^element type- 'deviceType" /> 

<element type= n rxiendlyName" /> : 
<element type="rnanufacturer" /> 

<elemienttype= , 'manufacturerURL ,,: minOccurs= maxOccurs-T* /> 
<elementtype="modelDescriptiorl <, minOccurs="0" maxOccurs=" 1" /> 
<element type="modelName" l> , ; 

<element type="modelNumber" minOccurs- '0" maxOccurs^" i"/> „ 
<elemeht type="modelURL" minOccurs="0" maxQccurs="l" /> 
<element type="serialNumber" mmOpcurs-'O" maxOccurs-T' /> 
<element type="UDN" /> : : 

<element type=="UPC" mmOccurs="0" maxOccurs= n 1" /> : , 

<element type="serviceList" /> 
<element type= n informationCategoryList n 7> 
</ElementType> ' 

<ElementType name- 'deviceType" dttype- W content- 'textOniy" /> 
<ElementType name- 'friendlyName" dt:type="$trmg" conte^^ /> 
<ElementType riame= ^ manufactur6r ;,, dttype- 'string" content="textOnlt" f> 
<ElementType name^ ^ manufacturerURL T, dttype- 'uri" content^"textOnly" /> 
<ElementType name= M modelDescriptidn" dt:type= ,? string° content="texiGnlv" '!> 
<E!ementType name= n modelMame M dttype- 'string" content="textOnly" !> 
<ElementType name="modelNiim]ber" dt:type= M strins M content= n t^xtQniy /> 
<ElementType name="modelML" dt:typ£- ,r uri M content="textOnly" /> 
<ElementType name^"serialNranber" dttype- 'string" content="text0nly" /> 
<ElementType name="UDN" dt:type="uri" content="textOrilV" /> 
<EIementType name="UPC" dt:type-"string" content="textOnly" /> 
<ElementType name="serviceList" content="eltOnly"> 

<element type= "service" minOccurs-T r maxOccurs- '*" /> 
</ElementType> ; „/l 

<ElementType name- 'service" content="eltOnly"> 

<element type="serviceType" /> 

<element type="serviceld" /> >\ < 

<element type^ ' ' S CPDURL " /> 

<element type="contro!URL ,f /> ; > ! 
<element type="eventSubURL" /> ; _^ 
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: </ElementTvpe>> , , ; ; ; < ;\ ; :> > \ * > — - - - ' " " \' : * -> « 

<Elem^^ ^ >' ' . 

<ElemdntT ype name— f seryibeld" dt:type= ,, uri , \cpntent— textG)nly'7> " ; . 
^ " / : ! ; 

<ElementType :, ife^^ ,f cqi^toltJ&L ,f dttyjs^un 1 '^ /> , w , t \ ; < 

<ElementType name="eventSubURL" dfcl^peN^i" co;ntent="text(My" /> , ; J< : 

<Eleme^^ 1 

<dlem§ijt type= ,? ihfoririaitip|(iCate2ory" minOceurs= f *l" roaxOecurs-'*" f> K \ <. .> 
</EIemen|fype> ' *' ::«!;:'' , '! f M : ; \^ u a 1 1 ' ' 

<EIementT^ - i \ I t i 

^ 1^ , , > : < * : < - " 

^lementtype^ Information 
i ^ />! « 

■ ' </EIementType* ; ; , r r ; :i < ^ ! : \,\ > \ - - <> > - : , ' " * ' 

<ElementType^ame^" Information^^ coatertt= ft teXt6niy" /> 

<ElementType riame^'^nfprmationC^^ 

<elementfVp^ 

</Elementf ype> ' ' ; ! 1 1»« > „ ' ' ' <: "' * * ' ; ' " J * " „ > « - ' r ' " , , ! - 

<ElementType natoe^'m^^ content="dtOniv"> 

<element type= , MnformationtateeoryBlockedKeyword ,? minOccurs= M 0 M maxOcpurs= ,, * n l> 
<EIementtype riame="; InfprInationCate2oiTKeywoM T, dtrtype-'iiri" conteii?= ,f textOrily " /> 
</EIemeritType name- ' InformationCategoryBIockedKeyword" dt:ttpe==' r uri^ content="textOnly" l> 
</Schema^> ' ' ' .» » <i « t ' ' _ ; , - \ , < ■: 

TABLE 3 

As shown in Table 3, the "informationCategoryList" is an element that lists one or 
more "informationCategory" elements, allowing the user the opportunity to select multiple 
categories of information to be presented on the device. For each "informationCategory" 
element, sub-elements "InformationCategoryName", "InfoimationCategoryKeywordList" and 
"InformationCategoryBlockedKeywordList" allow the device to specify, respectively, within 
the device description page: a common name for the information category, keywords which 
can help identify the information category selected if there is no exact match to the 
information category name on the control point, and blocked keywords, which can be used to 
identify types of categories which are not to be presented by the device. To allow the user to 
list keywords, elements "InformationCategoryKeywordLisf and 

"InformationCategoryBlockedKeywordList" are implemented as lists, having a single sub- 
element "InformationCategoryKeyword" and "InformationCategoryBlockedKeyword", 
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respectively. The "InformationCategoryKeywordList" and 

'TnformationCategoryBlockedKeywordList" elements can contain no elements, allowing the 
user not to specify keywords if they so choose. 

Returning to Figure 3, an EPF 124 is shown in the living room 106. The EPF 124 can 
5 present to the user an interface to allow the user to select the image or video clip categories to 
be presented on the EPF 124. As will be described further below, the user can be presented 
with a generic list of categories of images to be displayed, and an opportunity to enter 
keywords to further define the categories. Thus, for display in the living room, the user might 
. s select a "family" category and a "friends" category, and can enter further keywords, such as 

g 10 the names of the family members, or the locations that the family went on vacation to further 

ST define the category of images. The user can also be allowed to enter keywords of images the 

HI 

4? user does not wish to be displayed in the living room, such as advertisements, coupons, or 

* . delivery room pictures of the user's children. Once the user has made these selections, the 

{jess 
jj .. 

ri EPF 124 can create a device description page such as the one show in Table 4, below, 
p 15 Using an extended schema contemplated by the present invention, such as the one 

(ESS 

illustrated in Table 3 above, the device description in Table 4 can contain information 
regarding the types of images the user wishes to have displayed on the EPF 124 in the living 
room 106. For purposes of illustration, the elements of the device description in Table 4 
which take advantage of the extended schema of Table 3, are shown in bold type. As can be 
20 seen, the element "informationCategoryList" provides a listing of the categories of images the 
EPF 124, acting as a device, is capable of displaying. The categories are each defined by the 
"informationCategory" elements, which, in the exemplary device description provided in 
Table 4, include the categories named "family", "friends", and "blocked." Each of these 
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categories contains sub-elements which allow for key words. Thus, the "family" category 
contains a sub-element "informationCategoryKeywordList", which, in turn, contains further 
sub-elements storing key words to further describe the "family" category. In this manner, if 
the control point sending the images to the EPF 124 does not have a "family" category, it may 
still be able to identify certain pictures to be sent to the EPF based on the key words provided. 
Similarly, the "family" category also contains a sub-element 

"informationCategoryBlockedKeywordList" which contains keywords of images that should 
not be sent to the EPF. For example, the device description of Table 4 provides that images 
described by the keyword "delivery room" should not be send to the EPF 124 in the living 
room 106, even if such images are properly within the "family" image collection on the 
control point. 



<?xmlversion=''1.0^?>. \[ ; ; >: ; 

<rOot xmlns= n um:schemas-upnp-brg:device-l-0' , > , m. v 

<specVersion> ' * < , 

<maior>K/majdr> %v , , < , ; ! 

<minor>0</minor> <: ; ; r ; 

;|]|;f;l </spec;Version> . * > ; 

: <device> r > t : ' " 1 1 . 5 " ; , - 

<deviceType>um:scto , „ 

^ffiendlyName>Eleetronic Picture Frame</friendlyName> 
<manufacturer>EpfCo</manufacturer> \/- 1 . , 

<manuFacta^ 

<modelDescription>LCD Picture Fraiirie</modeiDescription> - 
<modelName>DigiFrame</modelName> -* ; \ \ 

<modelNimiber>2</mGdelNumber> J _ 
<modelURL>http^ ' 
<seridNumber>987-653210<serialNumber>\ : . „ 

<UDN>9876:543</UDN> ^ 
<UPC>DF2-9876</UPC> , 
iffDft ; <serviceList> 

<service> ' ' ' ( ! 1 * ' • ' 

<servicefype>uni:schemas-upnp-ors:service:epf:l</serviceType> « 
<serviceId>um:upnp-org:^erviceId:epf<&^i:yiceId> • { „ 

' <SCPDURL>display.xml<?SGPDURL> ; ' ; 
<coritrolURL>displaycontroLxml</controlURL> 
</service> , I - • " > . - 

<service> - \ . , , 
~ a second service can be< described here, - » } < 
: </service> _j - . 
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</serviceLisf> ;> > : > 

<informationCaiesdvList> : ; , ) ; < 

<inifor;niaf joriCate2pry> 

4 ! , ; - <mfqrmationCate2oryKeywordList> : K / ;^ 




<3nf3rmatiOBC^ 

</mforma*ibn^ , .« . r , ; \ t 

<ihfdrmationCate2oryBI6ckedKey wordList> 

<informatiottCate|£oryBlbckedKey^ 

</jnfoi;mationCate2oryBIockedkeyword > 
</mformat^ 
</infqrmajtionCate2orY> ; ; : 

</informatiQnGate2ory> 
<informatioiieate2^^ 
<informationCate2bryKeywordList> 
^ <informationCate2or^^ 
I, <informationCatte26rvKeyw^ 

<informationCate2oryKeyword^ 
<3nformationC^ 
</informatioriCate2oryKeywordList> 
</inform^tionCaie25orv> , I 

<informationCate2oryName>bIocfed </infprmationCatei2orYNairie> 
<inf6rmationCate2oryBlockedKe^ywbrdList> 
<iflformatiorieate20 
</infdrmationCate2oi^BIockedK^ 
<inforinati6i*Gafe^ 

</informationCate2onfBlbclfedKeyword > 
</informationCate£oryBlockedKfeywordLisipr 
</mformationCate26ry> 
; </inf6rmationCate2oyList ^ 

</device> - . ;> * > ' ' ' t . , . % , ' ; 
</root> ' : , , . . ' ' . 

TABLE 4 

The present invention contemplates that the information categories can be used, not 
only to enumerate those categories which the user wishes to have displayed on the device, but 
also to enumerate those categories which should not be sent to the device. The illustrative 
device description document shown in Table 4 contains an information category named 
"blocked" that contains no keywords, but does contain blocked keywords. Images matching 
the blocked keywords will not be displayed on the device even if they otherwise meet a 
selected category. Because, as shown in Table 3, the schema does not require a single entry in 
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the "informationCategoryKeywordList", it is possible that an information category exists 
which contains no keywords. Similarly, because the schema of Table 3 does not require a 
single entry in the u informationCategoryBlockedKeywordList" ? it is possible that an 
information category exists which contains no blocked keywords, such as the category 
"friends" shown in Table 4. 

Turning to Figure 5, an exemplary set of communications is shown using the schema 
extensions contemplated by the present invention. The control point 180 can be the 
computing device 20. The computing device 20 can contain the images to be displayed in an 
image store 43, which can be located on a local storage medium, such as hard disk 60, or 
downloaded from a remote computing device, such as through the Internet 50. The images 
may be categorized into different folders or databases, or they may have keywords associated 
with them, such as can be done with a digital photo album. The EPF 124, acting as device 
182, can broadcast, at step 186, its device description containing, in a manner similar to that 
described in Table 4, the user's preferences regarding the nature of the images to be displayed. 
Upon receipt of the device description page, the control point 180 can compare the categories 
and keywords listed by the device 182 with the images contained within the image store 43 to 
determine whether it is appropriate to request the device to display any images. 

If the control point 180 cannot identify any images within the image store 43 that 
correspond to the categories or keywords provided in the device description received at step 
186, then the control point 180 will not perform a request for additional services at step 189 
and there will be no further communication between the control point and the device 1 82. 
However, if the control point 180 can identify images within the image store 43 that match the 
categories or keywords provided in the device description, it can request a service information 
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page at step 187 to determine how to display the identified images on the device 182. As 
shown in Figure 5, the device 182 contains at least one service 184, whose functionality is 
described in a service description page. The device description page of Table 4 enumerates a 
service information page called "displaycontrol.xml", which can be requested at step 187. In 
response to this request, the device can return the "displaycontrol.xml" service information 
page at step 188. An exemplary "displaycontrol.xml" service information page is shown in 
Table 5 below. As can be seen, the exemplary service information page of Table 5 defines 
two actions: "GetDisplaylnfo" and "Putlmage". As will be explained further below, a control 
point can use a URL, by issuing an HTTP "get" command, to obtain information from a 
device or request that a device perform an action. Thus, as shown in Figure 5, at step 189, the 
computing device 20 can use the "GetDisplaylnfo" action to request information from the EPF 
124. At step 190, the EPF 124 can return the information requested. The "GetDisplaylnfo" 
action defined in Table 5, below, contains a number of defined variables, including: the width 
of the display of the EPF 124, the height of the display of the EPF, and the color depth display 
capabilities of the EPF. Given this information, the computing device 20 can scale an 
appropriate image to fit the display capabilities of the EPF 124, and can request the EPF 124 
to display the image at step 191. A confirmation can then be returned at step 192, if 
necessary. 



<?xml version="1.0"?> 

<scpd xmlns= n um:schemaS"Upnp-org:service-irO ,, > 
<specVersion> 
<maior> 1 </mafor> 
<minor>0</minor> 
</specVersion> 
<serviceStateTable> \ * 

<stateVariable sendEvents="yes"> 
<name>CurrentImageURL</name> 
<dataType>uri</dataType> , 
</stateVariable> 

<stateVariabie sendEvents- 'yes"> 



<Cnatiift>ItTiaifffiTif1p<:/ri?jtTip> 




<H^taTvnp>«Jfrma</rlfit?iT\/np> < » - " ' 4 
^uxiui 1 y jjc^ oti ii u.aici x ypv^ < :> : 








<state Variable sendEvents =t, ves*'> « 


, 1 < " ' 


<name>Ima2;eAtithGr</iiame> ; > , N 




>v*cllcl 1 ;y ^C^olXJUl£I>^7 \X<X\,aX<>y [Jv^. ^ ' ; ' / 'I t 


1 M - * , . . - * « 




: s <7ct atp\/fiH?iHlp> > - 1 < l > >' I 


"> !' 1 ' j 


^oLciiw-v^cii icil-'jl^ otxivxj^v txjxa y vj ^ -, ■.><>. - 




<^naliiA^TrnQO'P k ^iiKiP'ot<^/r)!StTi< :i "> > ' ' *» > ' 
^llalilC^xill<l^COUU|v^l^/iiaillC-^ 0 j v < - > 
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<n atrie>f rna pftF)afpTi mpTakpn</n amp> 

> ^IlCUIXw''^ XlllU-^VXVCllV X XliXv XrdJVVII lldlllV''^ 


" *i <i * * * '' ' " 


<THataXvnp>'QtHincr<?/rl?it5» , Tvnf k '!> ! ' - ' > > 
^vi«-ia. x y pc^Dixxii^r^/jVittjLcix -ypC'*^ ^ ( 


' « ' , - *' ' J " 
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<dataTvne>iin'4</dataTvne> ; » ' 




</stafeVariable> 




</serv!ceStateTable> 




<^aGtionList> — 




<action> n \ , , ; \ 




<name>GetDisplayInfo</name> 




<argumentList> - ... 




<argumexit> 5 




<name>Width</name> 
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<relatedState¥ariable>DisplayWidth</relatedStateVariable> 
<direction>:put^/difectioh> 
</argument> ' 
<argument> ^ ; " A ' ^ ; " " y yy> ■ ; , : « : : * ! ° \ " : 

4 ' - <name>Height</name>; ' i> : ; 'j !' ! { V ^ ^ T ^, x \ : , \ * . - > >, . - r - » " ' - 
<relatedStateVariable>M^ / : ; 

; > - <dkection>out</direction> , , /\; y ' \ 

<argument> * * i;;f^> / Y'll W.\* x \ ; , r - . ; 

<name>Cbloi*Depth</name> , - i: :> \ _ ^ i ? ; ; 

j <EelatedStateVariable>Di^ ' <J 

<direction>out^iitctitmJ> ; v- : : ; i ? ! : ; 
? ; ' ^/argument> < / i! - % !! ; / - ! I '«* : 

' ^ai-^timentList^ \ « ^ > / - - ^ ; - 

</action> , . ] ( ! ^ ! i> ; — '> ; M , » '! J > L </:' 

<action> - : 5 : ' ^ ,! ; ' 1 > - 5 < _ ; 

<nam|e>PutImaRe</name> , \ / , ; '.I \ \ ' „ 

<ar£imehtList> , ; ; ; - t 

<argument> . « % ?> : % : < ; , ; " ; ; <> :; : \ 
<name>Ima£eURL</name> \ j> ) \ ' ? ; ' I ; 

<relatedState Variable^ 
<(lirection>in^/difectidri> 
</ar£ument> ; , , « " j ^ - ' " ! : 

<arRument> — ' 1 , s ; . „ , ' ' o [ t 

<name>ImageTitle</name> <■ ;; ;; , 

<relatedS^^ / \. t 

<direction>in</direetion> 
</argume4t> . , ' s ' ' ' • , '> , 

<argumen£> ' ' 5 ; ; , 

<name>JpageAuthor</name> ; < ; , ■ 

<relatedStateVariable>Im^eAuthor</relatedStateVar^^^^ 
( <direction>iri</direction> M , , , ;> , 

</argumerrt> ■ ; , , 

<ar^ument> , ! ' . \ ' 

<name>ImageSubiect</nam^> 41 ; ( 

<relatedStat^Vafmble>MageSubiect</relatedStat^ 
<direction>in<y'dir^ctiph> < \; 

' </argument> > , 1 ^ t ' ! \ / \' ' - ' - : \ > U ; , , 

<ar.^ument> ^ > « j m - ^ ; , — ; ^ ; , ,: ; ; ; _ ^ 

<name>ImageDateTimeTake</name> : ; , ' 

. 0 <relatedStateVariab!e>^^ 

<direction>in</direction> ' , t - 

<argument> \\ < ( , 1 

<name>ImageGpisLatitude</name> , ' 

<relatedStateVariaWQ>ImageGpsLatitude</relatedStateVariable> 

<direction>in</dir6ction> 
</argumeivt> s < ; 

<argument> t ' , 

<name>ImageGpsLongitude</name> , ^ t \ 
< <relatedStateVariable>ImageGpsLongitude</relatedStateVariable> 

<direction>in</direction> 
</argiurient> \\ - - 
<argument> - : / 
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111: <name>ImageAcmalWiyM</name> r' « 

<relate4^ateV^ : ; 

<direifti^n:>Jn</directioii> ' ' * -> ■ ' 5 > 

> </aitgument>: '' > ' t _ - ' ; — i «" > ? i < . ' r ' ; - ' . 

<argument> - - *. t >' t ' \ " ^ ' [,'[, : : > :> > . 

<name>imageAbt^ialHeight < ^ame> ; - ' 

■;y^f - <relafedStete^ ; 

<dire;ction>iii</direction> J . :ni : > : - ; ' - 

; : J;K o 5 ' </argument> ; - * ;> (> : 

<arRument> 1 ; ' <; ;> ' <: ' ; : ' ^< < J: , . v " - * 1 - 

« <name>ImageAbfualColprDepth</Bame^ h 11 f ; 

r « •> relatedState Variable^ ; , 

' : w r ^ircctic^in^direoffein^;' , . ; , , % , ; ' ' - " = ; /, I t > ' ( 

■ ; </argraxient> \ ' % ; : ; „ „ „ «, < - , ^ ; ; c / ; ' ; : — „ „ „ : : * / ' \ ' 

</argiirhentList> { - > '' • : : > - - - - - • ;: <: : - ' ; ' 

Jlllf! </action> : - ' t , . ; . "" 

: </actionList> ^ , : < t _ t - - ° " "' 4> <f > , , , ^ > % ; * ( - * 

</scpd> '« ; '> , - j . ' *>[ 

TABLE 5 

The "Putlmage" action defined in the exemplary service description page of Table 5 
above, contains both the location of the image and arguments for passing image "metadata" - 
data about the image. The "ImageURL" variable can contain the location of the scaled image, 
which the EPF 124 is to display. The arguments, however, can contain further information, 
which the user can select the EPF 124 to display together with the image. For example 
"ImageTitle", "ImageAuthor", and "ImageSubject" can contain information about the title, 
author, and subject of the image taken, and can be edited by the user. Additional variables can 
contain data imprinted by a digital camera. For example, "ImageDateTimeTake", 
"ImageGPSLatitude", "ImageGPSLongitude", "ImageActualWidth", "ImageActualHeight", 
and "ImageAcutalColorDepth" can contain a date/time stamp, a location stamp, and image 
data as recorded by the digital camera or other digital image capture device. 

As an alternative to the modifications to the schema of a UPnP device disclosed 
above, the present invention also contemplates an information presentation appliance, which 
traditionally would act as a device under the UPnP architecture, acting as a control point. For 
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example, EPF 124 can become a UPnP control point on the UPnP network 4. With the 
information presentation appliance, such as EPF 124, as the control point, an image store, 
such as image store 43 in computing device 20 would become a device. The control point 
would search the UPnP network 4 for devices which contained information, or would wait for 
devices to advertise themselves, and would request that the device send the information to the 
control point to be presented to the user. As can be seen, by using an information presentation 
appliance as a UPnP control point, the presentation of information is changed from a "push" 
model, in which the information store pushes information to an information presentation 
appliance, into a "pull" model in which the appliance finds appropriate information stores and 
pulls the information from those stores that have the information it seeks. 

Table 6 below contains an exemplary device description such as might be used by the 
computing device 20 to advertise its collection of images 43. As will be obvious to those 
skilled in the art, an analogous device description can be used for the collection of audio files 
44, or any other information that can be presented to the user. As will also be known by those 
skilled in the art, a complex appliance, such as computing device 20 can act as more than one 
UPnP device. Thus, the computing device 20 can simultaneously act as a picture server 
device, serving images from the image store 43 and a audio server device, serving streaming 
audio from the audio store 44. 



<?xml version= M L0"?> > :; % 

<root xmlns= r 'uni:schemas-upnp-orR:device-l-0 M > ' : ' j 
<specVersion> , . 

<major>l</maior> ' 1 

<minor>0</minor> \ % 
</specVersion> ' 

<device> ; < , 

<deviceType>um:schemas-upnp-org:device:PictureSharer: 1 </deviceType> 
<friendlyName>%s Picture Sharer</friendlyName> . . 
<manufactoer>Microsott</manufacturer> ' 
<manufacturerUl&>fr^ 
<modelDescription>Microsoft .Net Picture Sharer<:/modelDescription^> , , 
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<modelNam£> ; Mcrosbft! .Isfei Picture Sharer ^/modelName> 
^odelNimiber^l.O^modelNumber^ I ' , 1 ; , : 

<mo;dplURt>h^^ 

<serialNumbfe^ ; /.',/''*" V , „ , 

<UPC>l</UPC> ; / . V r ; :: v :: ;[ ; : ; [ : \ :; i ;; „ ' * : \\ " ; - 

<serriceLis£> . „ . ^ . . - , - v . «, , , , . . - T > . - f - : > > " 

' . ° <service> ^ _ , ; M " £ 3 ) i \ 

<serviceType>ura:schemasHipnp^^ « ;| ? 

; <serviceId>tM:upnp^Qra:setvlceId:PicW 

<cbkroiiM><^(H^ ' " 0 ] ' " ) \ : ; ' ' : " ' : 

^ <eventS^bU^</eveptSubURL> ; ; ; <{ , < : - 

</strvice> J ° ' ' : — < - - . . , » - . , < ; . r : - - ; • •. ; ' 

<service> * > - ■ , ^ ; ; 

„ -- a second service can be described here ; 
</service>< - * - ; ' \ ; 1 ; , * > , / 

</serviceList> , , - , ' - * - 

lOISl^' </device> s _ , ,* , , . / . - ' : * ' - 1 
</root> J > ; ' : > ■. / II: II L ; " :: . ■ > < . 

TABLE 6 

As can be seen from Table 6, the "Picture Sharer" device exposed by the computing 
device 20 does not need to use the exemplary extended schema of Table 3, and can use a 
standard UPnP device schema, such as that shown in Table 2. The "Picture Sharer" device of 
the description illustrated in the Table 6 above exposes a service "PictureStoreAccess" which 
allows a control point to request specific categories of images to be displayed. Table 7, 
below, contains an exemplary service description page of the "PictureStoreAccess" service. 
The exemplary service description page of Table 7 allows the control point, implemented as 
the EPF 124, to request the categories of pictures, or "albums", available on the "Picture 
Sharer" device and to request information about each of the albums, including a name of the 
album, a preview of the album, a default play direction for the images in the album, a default 
play mode for the album, the number of pictures in the album, and a URL for accessing a 
picture in the album. 

As can be seen, the exemplary service description page of Table 7 provides for four 
actions which can be invoked by the control point: "GetNumberOfAlbums", 
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"GetAlbumldList", "GetAlbumlnfo", and "GetPicturelnfo". The "GetNimiberOfAlbums" 
action can contain a single argument, "NumAlbums", which is returned by the "Picture 
Sharer" device and contains the number of image albums the device can send to the EPF 124. 
If "NumAlbums" is equal to zero, then the EPF 124 can indicate to the user that there are no 
5 published albums on the "Picture Sharer" device. The "GetAlbumldList" action likewise can 
contain a single argument, "AlbumldList", which is returned by the "Picture Sharer" device 
and contains a comma delimited list of identifiers of image albums the device can send to the 
EPF 124. The "GetAlbumlnfo" action can contain a number of arguments for passing 
information from the "Picture Sharer" device. The "Albumld" argument can be sent as part of 
Sj 10 the "GetAlbumlnfo" action to the "Picture Sharer" device to identify the album from which 
SJ the picture can be retrieved. The "GetAlbumlnfo" action can then return the arguments: 
4* "FriendlyName", which can be a name given to the album by the user or the album's creator, 

"NumPictures", which can contain the number of images in the album, "BasePictureURL", 
|pJ which is a URL that can be used by the control point to request an image through an HTTP 
p 1 5 "get" command, "BaseFileURL", which is a URL that can be used by the control point to 

request an non-image file through an HTTP "get" command, "PreviewURL", which is a URL 
that can be used by the control point to request a preview of the images in a specified album, 
"PlayDirection", which can contain the direction of the display of the images through the 
album, "PlayMode", which can contain the mode in which the images are displayed, and 
20 "DisplayTimeSeconds", which can contain the number of seconds to display each received 
image. The "GetPicturelnfo" action can also contain a number of arguments for passing 
information from the "Picture Sharer" device. As with "GetAlbumlnfo", "GetPicturelnfo" 
provides arguments for identifying the picture about which further information is required, 



namely: "AlbumID" and "PictareNumber", which can be passed to the "Picture Sharer" 
device and can contain, respectively, an identification of the album in which the picture is 
located, and the number of the picture within that album. The "Picture Sharer" device can 
then return the following arguments: "ActualPicture Width", "ActualPictureHeight", 
"ActualPictureColorDepth", "PicutreFileName", "PictureTakenTime", "PictureTitle", 
"Picture Author", "PictureSubject", and "DisplayTimeSeconds", which can contain, 
respectively, the width of the image, the height of the image, the color depth of the image, 
user given name of the image file, the date imprinted on the image, such as by a digital 
camera, the title given to the picture, the person who took the picture, the subject of the 
picture, and the length for which the picture should be displayed. The "GetPicturelnfo" action 
also provides an argument "PictureURL", which can contain the full URL for the picture file 
on the "Picture Sharer" device. 



<?xml version= ,t LO t, ?> 

<scpd xmbs= rt urn:schemas-uphp-org: service- 1-0"> 
<specVersion> ° ' ? t ; 

<major>l</major> . , . 

<minor>0</minor> , ; 

</specVersion> . ; 
<serviceStateTable> • - • \ • ; 

<stateVariable sendEvents= M yes"> ' ; 
<name>NurnAlbums</name> 
' <dataType>i4</dataType> 

</stateVariable> 

<stateVariable sendEvents- 'ves";> 

<name>AlbumIdList</name> 

<dataType>strin^</dataTYPe> ; - ; , ! 
</stateVariable> ' « . 
<state Variable sendEvents™ 'yes"> , 
■•:H;jj;U; : . <name>LastChanaedAlbuin</name^ , , 

<dataType>string</dataType> 
</stateVariable> 

<state Variable sendEvents= M no n > : 
<name>A ARG TYPE String</name> 
<dataType>strin£</dataType> 

</stateVariable> ; 

<stateVariable sendEvents="ho"> ' 
mM <name>A ARG TYPE URI</name> 
<dataType>ur i</dataType> > 
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</stateVariable> «. ; 

<state Variable sendEvents="no ,, > 

<name>A ARG TYPE Int</narne> : - \ 

' <dataTYPe>i4</data^ype> > <; ; L : ; : , j ; \, « . . . ; < ; 
f ||l </stateVariable> ^ r r » n; : 4 :{ i i : > > .>:$;*' ' > :\ « ;* " 

- <stateVariiable sendEvents- 'no"> 
1 1|| <^am^A< > AR& TYRE PlayDirection</name> , < / 

<dataType^string</dataType> : : : : . 

lllll ' <allowpdYaljieList> 

<all^wedValue>FORW ARD</allowedValue> 
<aliov^ ; , 

<altowedValue>sffi 
|3|§i </aUowedValueList> 1 : ° f r " • ■'■ ' x - ' " " :; 

, <default¥alue>F0RWARD</defaiiltValue> 

111111 </stateVariable> ^ < , > , , , , s ' v ; " ' ' ; , 

<stateVariable sendEyents="no"> 
<name>A ARG t^Pi PlayMode</name>, ' ,1 \ ' , 
<dataTYPe>string</dataTvpe> : o ; : > , 
<allGwedValueList> 

<allowedYalue>01^GE</all6wedValue> ' 
<allowedValue>REPE^^ 
</allowedyalueList> 

;!<defaul^ ' [ 

</stateVariable> 
</serviceStateTabie> 
<actionList> - - 

:;:|;S| <action> - 

<name>GetNumberQfAlbums</Mme> : ; 
<argumentList> ■ i < z ii' t <' >,* v « 

<argiiment> \ , : > : ; 

<name>NumAlbums</name> ' 5 ; ; 

<relat€sdStateVariable> 

NumAlbums . .,.>:, 

</reIatedStateVariable> 
<direction>out</direction> 
</argument> , «:<':',< • ' 

llll </ar^umentList>< "' " " ' , 
</action> ; 
flfjf <action> _ , • <• , :< , ' ' " ^ 

<name>GetAlbumIdList</name> - < 
<argumentList> t ; 

<argument> , „ .; : 

^name>AlbuinIdkist</iiame> „ 
<relatedStateVariable> 

A ARG TYPE String , 
<7relatedStateYariable> : , 

<direetic>n>out</direction> 
</argumerit> 
llll , </argumentList> 

</action> , „ f ; : ' 

mm <action> * \ 

<name>GetAlbumInfo</name> 
<argumentList> 

<argument> . ' : 
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<riame>AibumTd^/name> . „ , ;> « , m a . % / . . < 

<relatedStateVmable^ , , 

- ; 1 ARG ! TYPE String ' - ' ; ; 
</r ; elatedStateVaria!>le> - v ' > > . ' - \ . . 
<direction>in</direction> j - ; ; . < ; : <, ^ , ^> 

, </arRument> • . ; : • ; . : ; ' 5 / / J 1 • i< n \< 1 , :\M } ¥ ? ; ; ; = ,1, ! " ; 
<argument> 

, <naine>FriendlyAlbiimName^/name> , . 4 , 
; . > > ><reMedStatteVa[ri^bfe^ s * '« s :> : ^ < ! < s i> :> : ' !"\ i! . > , *' ' : - : - , i ji ? « , 
A ARG TYPE String 

jjUMl: [ : [ : : ; ; ; </rdat^Stat^^iabJe> , «! :j « ; ' ; ' : ; : j ; j, jn; ;p ; ; * ; ; > ; \\< { ;< > > > % ^ g ; <: <; 

; ;<direM^ : » f :i ; : 1 i' " i - » ! 5 ? : '< '! 1 !' I, ; 4 - ,C : r " i j ' : * r » - «- 

</argument> . < . * . . . , . . . ~ 

WSim <name>Nu^idWek<%toe> ' ' : >% ;s ; 5 * * ;> > ; '' 5 : ' > ' 

<relatedStateVariable> 
A ARG TYPE Int 
</relatedStateVariable> — 
<direction>out</direction> 
</argument> 

<argument> t ] % < ^ ^ [ u " * ^ " ^ " " 

<name>BasePiGtoeURL;<|name> \ f ,j i : ; ; , « ; < « ; 

<relatedStateVaria!ble> { : : , 

A ARG TYPE URI 

</relatedStateVariable> 

<direction>out</direction> 
</argument> t } < 

<argumerit> > - ' 

<name>BaseFileURL</name> * t i 

<relatedStateVariable> _ o , , ' : ' : 

A ARG TYPE ; URI , 

</relatedStateVariable> . 

<direction>out</direction> . 
</argument> '/ ; ; ; , 

<argument>: % 4 . ^ - - « . , - > . 

<name>Previewl)Rt</name> , x . 

<relatedStateVariable> 
A ARG TYPElURI ^ : ,■„;',;;; , ; ; 

</relatedState Variable^ , ' % <: — ' ' ^ — 

<directipn>>out</direction> , - , 

</argument> \ ^ t 5 , \ - , ( ; , 

<argument> ; \ < \ - « « < 

<name>PiayDirection</name> 

- / <relatedState Variable • • ; ; <' - :\ ' 4 , ^ <- ' 

A ARG TYPE PlayDirection ; ; 

</relatedStateVariable> , \ : . 

<direction>oiit</direction> ; ; ; 

WM. </argument> _ ~ : . - - - < > <: 

<argument> > -° 

<name>PlayMode</name> , ! , ; 
<relatedStat;eVariable> * ; 

A ARG TYPE PlayMode . 
</re!atedStat6Variai>le> ' - - 
iMii <direction>out</directidil> . ' ' ,__ 
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" 5, i / 


' • ^1 CldlCU^lalC V di laUlc^ , s , >r t . 




A AT?n TVPF Phi - 




WrcldlCuijLalc V dOdDlC--^ - - ' < , 






; , ' \ - - " v .. , . : - 


w <xi^uiiiC;i.ii^ ( : ' : ]' s 








s/aciiow^ s , ^ ■ ■• 












>-dr&UIHcniJ^l{>l^ \ , , , ; 




<flro r iimpnt> ; ' > 






\ : ! f <' . 






A ADn TVDti C+f*r»*Y° - - ' 

A AKvjr i YrJi btrmg ; 




</reiateaotate V anaDle> : ? 


i > " " ' , " 


<direction>i^<(cjirecf iort> * - : - 


' s ' : ' < 


</argument> ; «j \ \ 




' <argviment> -<'''" \ , 




<name>PictureNuniber</nanic^> 3 ; 1 > 




^reiaicuotate v ariaDie^ > 




A ARC TVPP' Tht 




wTcjateaoraid v anaDic^ 




<directiQn>in</direction> < 




^argumcnt^ , <> * - ! ' 


« 


^argumeiii^ s * 




^nanic^ACtuairicutre w laiJn^^/pBiiie^ 1 ^ 




^rciaieaoiaic v anaoie^ , 




A AKvj I iJrii lilt , 




wrciateaotatey anapie> > 




<directidn>out</direction> 




</argument> .' . 




^argunicni^ . < ^ < 


• ■ ; \\ ' ' : 






^relate a oiate v anapie^ 




A APf. TVPP fnt " 1 
A /iivy 1 ire llll 




>/rciaieaoiaie v ariapic^ 




<directi6n>out</direction> ' 




</argitment> ^ 




<argument> •; .. ■ [ - < - 




^n<uTic^AciuaixiCT^pOOiori^ 


^ i 


CialyuolalC V dTlaDlC'-^ ; 4 , 




I\ AKu i x Jrxi lilt v> < < 




wrcidicuoidic v anaoie^ 








drH,uiriciii-^ , 








<name>PictureFileNarrie</name> 




<relatedState Variable> . 




A ARG TYPE String . 




</relatedStateVariable5> 




<direction>out</direction> 
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</afgument> \ \ . \ \ \ ; ^ t - - 

WM : ' <argiiment> ■ !' r , <> - ^ « < - - ' «' " '\ 

<name>PictureTakenTime</name> , ^ . 1 > ^ ; 

<re!atedStataVariable> . • , ' , • " ' - : r ' , , \ . 

' 'A ARG TYMff; String! !! > [ ! " * 5 ' > < 1 " 1 

J ; ' <^relatedStateVariable> <' » ; 1 : 1 , ; :; - ' " V : : !; " ' 

<dkection>out</directiori^ ' J : , ; r , ~ 

|lj|J| </argument> / '* * y ! ] ' ' -y; y <: i"'' ' . \ y : : , 

/ : ■ ^ <argunient> * r ? * < ; 1 y ^ , , , « , g ,{ <> \ > ^ 

, <^am^ictureTitle</name> ; r 
iSli 1 ];! , , <relatedStateVariable> > , 1 „ , ; «' y „ ? : ;;>:>- ; :', : : , * - : < 

A ARG TYPE' String' > > : :> H ; < f i . : ; -\ \ : :r: . , _ ; , „ ; • f , ^ . . , 

</relatedStateVariabie> " - 5 < ' J « . , :< » IT' , t s , . 

<direction>out</direction> ,,,Mr: ' ; \ = ';';;'-'<' - ; ; > 1 '■ 

^HKM .. </argument> • < < - < u <, ^ < < 0 „ - ; ^ - ' ; ;t ' 

<argument> . , > ' < ^ • 4 * : ' ' » ' ; ' < ; ' 

<name^Pictoi;eAyf]ior5/name> r s . 
■■ « <relatedStateVariable> ' \ . 

A ARG TYPE String . ^ y< v , > : ' « . , < ; ( , , «. • . < : ^ . 

</reIatedStateVariabb> ' ' \ 
< <direction>out</direction> 
</argument> _ , ( ; < 

<argument>. % - - ^ ■ < ' « . „ . % , , , , x < , . t 

<name>PicUireSiibject</name>^ 

^eldteidState^arJabie^ /.><.. \:<. I s -*,<;:'> > ' 

A ARG TYPE String 
, > - </relatedStateVariabIe> ; - ; t :> < , , < , % K < f . ; „ > . 
<direction>out</direction> :> ' y 

</argument> < , ; 

<argiiment> . , , 

<riame>PidtureURL</name>;> ; ; < < - ; ; , , 

<relatedStateVariable> : ^ : ; > 

A ARG TYPE URI _ ; ; ( ; 

</relatedStateVariable> 

<direction>olit</diriection> \ 1 '.<',,; 

If </argument> ;: . d ' ' > ' n <: t ; > « /- : . 
</arguxnentList> < , , ; 
</action> 4 • - . ; ; .. .. - < ^ ^ J:'/- \ 'r 
</actidnList> /]] .J ; '! 
</scpd> - 11 r_ 1J : 'l_ ' _ ^ - ■ ■ '< - r ' ■ : 

Table 7 

As is known by those of skill in the art, a control point can use a URL to request 
specific information from a device. The URL is constructed to reflect the information sought 
and it is sent to the device using an HTTP "get" command. Thus, a URL can be constructed 
by the control point implemented in EPF 124 to request a picture, based on the 
"BasePictureURL" argument, of the form: http://host:port/localInfo, where the host is the 
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machine name of computing device 20 and the port is the port on computing device 20 
through which UPnP communications are being exchanged. Locallnfo can be of the form: 
ssisapi.dll?AlbumId=_&PictureNum=_&Width=_&Height=_&ColorDepth=_&S 

malllmages= where the "Albumld" is the identifier of the album, the "PictureNum" is the 

5 number of the picture requested within the album, the "Width", "Height", and "ColorDepth" 
are the maximum width, height, and pixel depth abilities of the display device, such as EPF 
124, and "ScaleSmalllmages" is a binary value which can allow images smaller than the 
requested width and height to be scaled appropriately. 
!^ The exemplary service description page of Table 7 also contains state variables, 

S 10 including: "A_ARG_TYPE_String", "AARGTYPEURT and "A_ARG_TYPE_Int", 

'i. , 5 

y which are of type String, Uri, and Int (or Integer), respectively. Some state variables can be 

+!. evented so that a change in that variable can be automatically communicated by the device to 

'L any control point that has subscribed to the eventing service, without the need for the control 

saw 

q point to specifically request the value of the state variable. The exemplary service description 
O 15 of Table 7 provides for three state variables that can be evented: "NumAlbums", which can 
indicate the number of albums available on the "Picture Sharer" device at a current time, 
"AlbumldList", which can be a comma delimited list of all of the album IDs published by the 
"Picture Sharer" device at a current time, and "LastChangedAlbum", which can indicate the 
last album that was modified. 

20 Turning to Figure 6, an exemplary series of communications are shown between the 

EPF 124, implemented as a control point 204, and the computing device 20, hosting the 
Picture Sharer as a device 200. The PictureSharerService is shown as a service 202 in Figure 
6. Initially, the device 200 can advertise its services at step 210 by sending a device 
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description page, such as the one shown in Table 7. The control point 204 can then, at step 
211, request the service information page, such as the exemplary PictureSharerService page 
shown in Table 7, which will be returned to it in step 212. As explained above, the 
PictureSharerService exposes a function "GetAlbumldList", which the control point 204 can 
call at step 213 to obtain a list of available albums from the Picture Sharer device 200. which 
can be returned at step 216. To more effectively present the list of albums available to the 
user, the control point 204 can, at step 217, perform a "GetAlbumlnfo" request on each album 
ID contained within the returned list. In this manner, the control point 204 can learn the 
names of each of the albums and present the user with their names, rather than their numeric 
identifiers, which can be meaningless to the user. When the device 200 returns the 
information of each album at step 218, a user interface 230 at the control point 204 can be 
created and presented to the user to allow the user to select which albums of images are to be 
displayed on the EPF 124. Once the user has elected the albums to be displayed, the control 
point 204 can request those albums at step 219, such as with an HTTP "get" command to the 
"BasePictureURL" as described above, and the device can return the images, at step 220, in 
the requested format, to the EPF 124 for display. 

The present invention further contemplates a user interface, such as the user interface 
230 of Figure 6, that allows a user to select the categories of information to be presented to the 
user from any given information presentation appliance. Figure 7 illustrates an exemplary 
user interface 230 contemplated by the present invention. On an initial screen 23 1 , the user 
can be presented with the names of any information categories that the information 
presentation appliance can present to the user. For purposes of illustration, Figure 7 shows an 
exemplary user interface of the EPF 124. The initial screen 231 contains categories of images 
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or video clips that are available for display on the EPF 124, including a "family" category 
represented by button 232, a "friends" category represented by button 233, a "vacations" 
category represented by button 234, a "business" category represented by button 235, a "baby" 
category represented by button 236, and a "wedding" category represented by button 237. An 
5 additional button 238 allows the user access to additional options. The categories provided on 
the initial screen 23 1 could have been derived from a Picture Sharer device, as described in 
detail above, or they can be generic categories which, once selected by the user, can be 
incorporated into the device description page of the EPF 124 using an extended schema 
s t contemplated by the present invention, as was described in detail earlier. 
S 10 To facilitate multiple selection, the selection of a single category, such as category 

Sj 235, can present a new screen 240 with the selected category highlighted. Once the user has 
JE completed all of their selections, the device can obtain the appropriate images or video clips. 
Alternatively, the user can select the "more options" button 238 and can be presented with a 
screen such as screen 250, containing additional options, including a "search" button 251, a 
S 15 "block" button 252, a "keywords" button 253, and a "settings" button 254. Also, a "home" 

"SEW 

button 255 is provided to allow the user to return to the previous screen. The exemplary 
functionality described in detail earlier, such as allowing the user to define images through 
keywords, or use keywords to block specific types of images from being delivered to the EPF 
124 can be accessed through a screen such as screen 250. The selection of one of the options, 
20 such as "keywords" button 253 can cause the display of a user entry screen, such as screen 
260, containing an input box 261 in addition to buttons 262 and 263, allowing the user to 
enter their input or cancel their input, respectively. The selection of either button 262 or 263 
will allow the user to return to the previous screen 250. The user's interaction with the EPF 
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124 can be through any number of hardware and software devices, including a mouse 17, or a 
keyboard 18, as shown in Figure 1, or though a touch-screen, a jog-dial, or similar device, 
which are not shown. 

Returning to Figure 3, each of the information appliances shown, including stereos 
5 122 and 130, EPFs 124, 126, and 132, and televisions 120, 128, and 134 can operate in a 

similar manner to that described above. The present invention is not intended to be limited to 
image presentation appliances, such as EPF 124. Rather, it is intended to be used with any 
appliance capable of presenting information to the user. For example, a stereo, such as stereos 
122 and 130 can present aural information to a user by playing sound files obtained from the 
S 10 computing device 20 such as from the audio store 44 on hard disk 60, or through the 
\l broadband Internet connection 112, including downloaded files and streaming audio files, 

== i 

£ such as through Internet radio stations. As described above, the stereos 122 or 130 can act as 
f either a UPnP device or a control point. If the stereos 122 or 130 act as a UPnP device, then, 

!T using an extended schema contemplated by the present invention, such as the extended 
f 1 1 5 schema shown in Table 3, the stereos 122 or 130 can allow a user to input different categories 
or keywords of songs the user wishes to be played through stereos 122 or 130. The stereos 
122 or 130 can then create an appropriate device description document, using the extended 
schema, to communicate the user's selections to control points on the UPnP network 4. The 
computing device 20, acting as a control point, can then obtain control over stereos 122 or 130 
20 and send sound data to them if the control point contains, in local storage 44, or though a 
WAN, such as the Internet 50, the categories of songs that the user has selected. 
Alternatively, if the stereos 122 or 130 act as a UPnP control point, then they can search for 
devices on the UPnP network 4 that can serve audio information, such as a "Song Sharer" 
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application operating on the computing device 20. The stereos 122 or 130 can then request 
the service description page of the "Song Sharer" application, and can further determine, as 
described in detail above, the categories of songs that can then be presented to the user. Based 
on the user's selections, the stereos 122 or 130 can then, through appropriate functions calls 
and appropriately constructed HTTP "get" commands, request that the "Song Sharer" 
application deliver the audio data to the stereos for playback. 

As can be seen, the present invention provides for a method, system, and apparatus for 
allowing a user to tune the categories of information presented to the user through individual 
information presentation appliances. In addition to the embodiments described above, the 
present invention can be used for many various applications. For example, an EPF 126 in a 
kitchen 104 can be tuned to present only coupons, allowing the user to send such information 
to the location where it most likely to be used. If a coupon is displayed that matches an item 
on the user's shopping list, the user can request that the EPF 126 print the coupon on printer 
1 16. Additionally, the user can tune a television 128 in the kid's bedroom 1 10 to prevent the 
television from displaying R-rated movies, or any adult content. The present invention 
contemplates the use of standard UPnP devices and XML schemas for those devices as the 
basis upon which the extensions described above can be added to enable the functionality 
contemplated by the present invention. 

All of the references cited herein, including patents, patent applications, and 
publications, are hereby incorporated in their entireties by reference. 

In view of the many possible embodiments to which the principles of this invention 
may be applied, it should be recognized that the embodiment described herein with respect to 
the drawing figures is meant to be illustrative only and should not be taken as limiting the 
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scope of invention. For example, those of skill in the art will recognize that the elements of 
the illustrated embodiment shown in software may be implemented in hardware and vice 
versa or that the illustrated embodiment can be modified in arrangement and detail without 
departing from the spirit of the invention. Therefore, the invention as described herein 
contemplates all such embodiments as may come within the scope of the following claims and 
equivalents thereof. 



